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□n  February  IS,  1386,  RADh  Chang  fired  the  Commanding 
Officer  of  the  Navy  Programming  Center  in  San  Diego,  relieving 
him  of  all  responsibilities  for  the  development  of  the  tactical 
command  and  control  computer  program  for  the  USS  THEODORE 
ROOSEUELT  CCUN  71).  RADfl  Chang  directed  the  program  manager  to 
go  to  San  Diego  and  take  over  control  of  the  day-to-day 
operations  in  the  program’s  development.  Uhat  prompted  him  to 
take  this  extraordinary  action?  In  order  to  understand,  ue  must 
first  look  into  the  background  of  the  program. 

Historu .  The  tactical  data  system  (TDS)  uas  installed  in 
Navy  ships  in  1361  and  represented  one  of  the  first  military  uses 
of  digital  computers.  Designed  to  display  and  coordinate  anti¬ 
air  uarfare  information,  the  system  automated  the  functions  of 
the  ship’s  Combat  Information  Center  CCIC) .  Prior  to  the 
installation  of  the  TDS,  information  from  radar  operators  uas 
passed  verbally  to  plotters  uiho  recorded  the  information  on 
large,  vertical  plexiglass  boards.  The  ship’s  officers  evaluated 
the  information  displayed  on  these  plots  and  verbally  assigned 
ueapons  to  engage  targets.  The  TDS  eliminated  the  need  for 
manual  plots  by  allouing  the  data  to  be  entered  into  a  computer 
uihich  then  displayed  the  target’s  position,  course  and  speed. 

The  system  evolved  through  the  decade  of  the  1360s.  The 
air-search  radar  and  ueapons  uere  hooked  directly  to  the 
computer.  The  system  then  automatically  collected  target 
information,  displayed  the  tactical  situation  for  evaluation,  and 
assigned  targets  to  ueapons  systems  at  the  push  of  a  button.  A 
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radio  data  link  uias  added  uihich  alloued  computers  on  several 
ships  to  exchange  information.  Figure  1  shouis  the  floui  of 
information  in  the  combat  system. 


Figure  1.  Combat  System  Information  Flou 


The  system  continued  to  become  more  capable  in  the  1970s  as 
anti-submarine  warfare  and  anti-surface  warfare  functions  were 
added.  The  TDS,  shown  in  Figure  2,  had  become  the  heart  of  the 
ship’s  combat  system. 


Figure  2.  Tactical  Data  System  Equipment 


By. the  end  of  the  lS70s,  tactical  data  systems  were 
installed  in  all  aircraft  carriers  and  cruisers.  But  they  were 
still  using  the  same  first-generation  computers  as  the  original 
1361  system.  This  computer  had  provided  yeoman  service  for 
twenty  years,  but  so  many  software  features  had  been  added  that 
the  computer’s  memory  was  filled  to  capacity.  Its  processing 


speed  slouied  to  a  crauil  uihen  even  a  moderate  number  of  targets 
mere  present.  Neui  requirements  uere  continuing  to  emerge,  driven 
by  the  installation  of  neu),  advanced  ueapon  systems  designed  to 
counter  the  technological  advance  of  the  Soviet  Union.  It  uias 
time  to  modernize. 

The  Initial  Program.  The  Naval  Sea  Systems  Command  received 
approval  for  its  TDS  Improvement  Plan  in  February  19B1 .  It  uas 
to  be  improved  using  a  tuio-step  approach. 

Step  One  uias  a  lou-risk  development.  The  Navy’s  second- 
generation  computers  mould  be  installed.  These  nem,  more  capable 
computers  had  been  operating  in  other  systems  for  several  years. 
Buying  these  proven  products  from  the  production  line  represented 
a  lou  risk  strategy  for  replacing  the  old  TDS  equipment. 

Neu  softuare  programs  mere  required  to  operate  in  the 
updated  TDS  harduare  configuration.  Again,  a  lou  risk  strategy 
uas  selected.  The  programs  mould  be  developed  uith  traditional 
programming  techniques  uhich  had  been  in  use  for  many  years.  The 
performance  requirements  for  the  softuare  in  Step  One  mere  kept 
simple  —  provide  the  same  functional  capability  as  the  current 
system.  The  program  manager  uas  located  at  the  Naval  Sea  Systems 
Command  in  blashlngton,  D.C.  The  cruiser  softuare  for  Step  One 
mould  be  developed  at  the  Navy’s  programming  center  in  Uirginia 
Beach,  uhich  had  responsibility  for  all  cruiser  and  destroyer  TDS 
programs.  The  aircraft  carrier  softuare  mould  be  developed 
its  sister  facility  in  San  Diego;  responsible  for  all  aircraft 


carrier  and  airborne  TDS  proorams.  Harduiare  delivery  utas 
required  in  FY  1304  for  a  neui  aircraft  carrier  and  in  FY  1385  for 
a  cruiser.  Completed  softutare  programs  utere  required  in  FY  1336 
for  both  the  carrier  and  cruiser.  Figure  3  shouis  the  schedule  as 
it  appeared  in  the  1381  Improvement  Plan. 

FY 

Step  One 
Cruiser 
Hardware 
Software 

Carrier 
Hardware 
Software 

Step  Two 

Carrier  Software  A 

Cruiser  Software  A 

Figure  3.  1301  Delivery  Schedule 

Step  Tuo  uias  a  medium  to  high-risk  softutare  development, 
incorporating  significant  functional  improvements  to  the  TDS 
program.  This  technologically  advanced  program  utas  to  be 
developed  using  a  revolutionary  neut  computer  programming 
technique.  This  neut  technique  allouied  for  faster  development  of 
high  performance  softutare  programs  at  a  reduced  cost.  The  key  to 
this  utas  the  development  of  computer-aided  softutare  production 
tools.  The  tools  utere  designed  by  personnel  from  both  of  the 
Navy  programming  centers  and  had  been  under  development  since 
1378.  The  programming  center  at  San  Diego  utas  managing  the 
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development . 

Step  Tuio  softuiare  uias  to  be  completed  For  the  aircraft 
carrier  and  the  cruiser  by  FY  1983.  These  programs  mere  to  be 
developed  under  a  cost-plus-auiard-fee  contract  starting  in  1984. 

Changes  to  the  Plan.  The  ink  had  hardly  dried  on  the 
original  TDS  Improvement  Plan  —  Step  One  and  Step  Two  —  when 
the  first  changes  mere  made. 

In  day,  1961,  the  Chief  of  Naval  Material  directed  all  neui 
programs  to  use  the  Navy’s  third-generation  computer  scheduled  to 
enter  production  in  1385.  This  change  ensured  the  Program  uould 
be  installing  the  latest  state-of-the-art  hardware.  It  also  gave 
TDS  the  dubious  distinction  of  being  the  first  system  to  field  an 
operational  program  in  the  new  computer.  This  change  increased 
the  Step  One  hardware  risk  but  was  considered  acceptable. 

In  June,  1982,  the  TDS  program  manager  decided  that  the  new 
software  development  techniques  being  used  for  Step  Two  were 
maturing  at  a  fast  enough  rate  to  support  development  of  Step  One 
software  programs.  Consequently,  he  directed  the  Uirginia  Beach 
programming  center  to  shift  the  Step  One  cruiser  software 
development  from  the  traditional  method  to  the  promising  new 
software  development  technique.  He  did  not  shift  the  aircraft 
carrier  program  to  this  new  development  technique.  The  third- 
generation  computer  would  not  be  available  in  time  to  meet  the 
construction  schedule  for  the  new  aircraft  carrier.  The  THEODORE 
ROOSEUELT  would  receive  a  second-generation  computer  and  a 
software  program  developed  using  traditional  methods. 
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The  decision  to  base  the  Step  One  cruiser  scftuare  on  the 
neui  development  techniques  increased  the  risk  for  this  program. 
But,  if  the  development  techniques  mere  successful,  the  scftuare 
juld  be  developed  faster  and  at  a  much  Icuer  cost.  The  payoffs 
uere  big!  Also,  because  the  scftuare  developed  in  Step  One  could 
be  used  to  fulfill  some  of  the  requirements  for  Step  Tuo,  the 
rr/.'sk  in  the  Step  Tuo  uas  reduced .  The  program  manager  decided 
the  payoff  uas  uorth  the  risk. 

Figure  4  summarizes  the  changes  in  the  TDS  improvement 
program  occurring  from  1S01  to  1905  and  gives  the  program 
office’s  assessment  of  the  risk  after  each  decision. 
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Program  status  in  19BB.  Three  uieeks  prior  to  RADh  Chang’s 


action,  a  new  project  officer  reported  to  the  program  office. 

CDR  Charlie  Bingay  arrived  literally  in  the  middle  of  the  flail. 
When  he  heard  of  the  firing,  he  inquired  what  the  problem  was. 

It  seems  that  the  simple,  low-risk  software  being  developed  for 
the  THEODORE  ROOSEUELT  had  not  worked.  This  was  discovered  in 
June,  1365.  The  program  office  had  devised  a  recovery  plan  which 
involved  installing  new,  third-generation  computers  in  the 
carrier.  They’d  recently  been  approved  for  production,  and 
converting  the  carrier  software  to  run  in  this  new  environment 
was  considered  a  good  move.  The  schedule  allowed  a  relatively 
short  period  of  time  to  accomplish  the  conversion. 

Fortunately,  the  San  Diego  center  had  a  small  group  of 
highly  proficient  programmers  referred  to  by  the  other  staff 
members  as  ’’The  flagnificent  Seven.”  In  this  case  they  were 
invaluable.  Once  they  became  interested  in  a  problem,  they 
tended  to  work  sixteen  hour  days  and  skip  meals  until  it  had  been 
solved.  They  were  given  the  Job  of  converting  the  carrier 
software . 

In  the  software  business  an  extremely  proficient  programmer 
is  called  a  ’’guru”  and  is  usually  somewhat  eccentric.  When  time 
is  limited,  they  are  invaluable.  A  guru  can  create  a  software 
program  and  make  it  work  in  half  the  time  required  by  a  normal 
programmer.  Unfortunately,  it  is  usually  difficult  to  get  them 
to  document  what  they  have  done;  they’d  rather  get  on  to  the  next 
problem . 

In  order  to  assist  in  the  carrier  software  conversion,  the 
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program  office  hired  four,  $80  per  hour  software  experts  —  gurus 
—  and  provided  them  to  the  San  Diego  programming  center.  Even 
with  this  high-priced  talent,  the  facility  commander  had  been 
unable  to  achieve  satisfactory  progress  in  the  recovery  effort, 

As  one  member  of  the  program  office  staff  put  it,  "he  couldn’t 
get  his  Magnificent  Seven  to  cooperate  with  the  gurus  from  out  of 
town.”  Apparently  the  Admiral  expected  better  team  building 
skills  from  his  senior  officers;  even  if  the  players  were  all 
prima  donnas.  So  he  relieved  the  facility  commander  of  the 
software  conversion  responsibility  and  told  the  program  manager 
to  leave  his  duties  in  Uashington  and  take  over  the  day-to-day 
management  of  the  effort  in  San  Diego.  The  program  was  required 
aboard  THEODORE  ROOSEUELT  in  four  months  —  this  was  definitely  a 
crisis  situation. 

Before  he  left  for  San  Diego,  the  program  manager  assigned 
CDR  Bingay  to  head  a  study  group.  He  was  charged  with  assessing 
the  state  of  the  new  software  technique  and  the  overall  Step  One 
and  Step  Two  developments .  The  program  manager  wanted  the  report 
”by  the  Ides  of  March.” 

In  his  short  time  in  the  office,  CDR  Bingay  had  learned 
something  of  the  status  of  the  program.  The  lead  ship  for  the 
cruiser  program  had  been  changed  and  the  software  was  now 
required  in  April,  1387.  Even  with  this  ten  month  delay  in  the 
required  delivery  date,  the  step  one  cruiser  program  was  four 
months  behind  schedule  and  seemed  to  be  falling  further  behind. 
The  step  two  program  budget  had  been  reduced  which  required  the 
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schedule  to  be  extended  tuc  years.  Figure  5  shous  the  TDS 
improvement  program  schedule  as  of  February,  1SB6.  Changes  from 
the  ISBl  schedule  are  shoun  by  dotted  milestones  and  arrous. 
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Step  Tvy/o 

Carrier  Software  A  ^A 

Cruiser  Software  A  -cA 


Figure  5.  1SB6  Revised  Delivery  Schedule 

CDR  Bingay  continued  to  assemble  his  study  group.  He  had 
been  advised  by  the  program  manager  to  gather  ”a  feu  unbiased 
experts”  to  help  uith  the  study.  Uery  quickly  he  discovered  that 
the  neu  softuare  deve'opment  technique  uas  highly  controversial 
—  there  mere  no  unbiased  experts!  He  settled  for  a  group  of 
six,  experienced  in  softuiare  development,  uith  at  least  their 
biases  regarding  the  neu  technique  a  knoun  commodity . 

The  study  group  first  visited  the  San  Diego  programming 
center  and  found  that  the  carrier  program  uas  finally  making 
satisfactory  progress.  Personnel  from  the  center  attributed 
their  recent  success  to  the  follouing  factors: 

a.  The  maturity  of  the  traditional  programming  techniques. 
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b.  The  availability  of  programmers  experienced  uiith  these 
techniques . 

c.  The  program  manager’s  ability  to  use  the  programming 
talent  effectively. 

There  uias  a  strong  feeling  in  the  San  Diego  center  that  this 
success  proved  the  value  of  the  traditional  programming 
techniques . 

Next  the  group  met  luith  the  Step  Tuo  contractor  personnel. 
During  these  discussions,  the  contractor’s  technical  staff 
pointed  out  tiuo  problems  luhich  they  felt  uould  prevent  the  Step 
Ttjo  program  from  succeeding: 

a.  The  neiu  programming  technique  uould  not  provide  the 
expected  enhanced  productivity  in  softuiare  production. 

b.  The  neu  programming  technique  luas  limited  and  uould  not 
allou  Step  Tuo  to  achieve  its  performance  requirements. 

The  contractor  strongly  recommended  that  the  Step  Tuo  development 
should  suitch  to  using  another  softuare  production  technique. 

Finally,  the  study  group  met  uith  the  Uirginia  Beach 
programming  center.  The  cruiser  program  uas  behind  schedule  but 
the  senior  people  at  the  center  uere  extremely  positive  that  the 
cruiser  program  could  be  completed  on  time.  Their  confidence  uas 
based  on  the  follouing: 

a.  Recent  improvements  in  the  neu  programming  technique  had 
resulted  in  increased  productivity  and  more  improvement  uas 
possible. 

b.  The  remaining  test  phases  could  be  overlapped  in  order 
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to  shorten  the  amount  of  time  required  to  complete  the  program. 

The  Uirginia  Beach  personnel  also  took  issue  uith  the  idea 
that  the  neu  programming  technique  ujould  not  support  the  Step  Tuio 
program  development.  They  successfully  refuted  some  of  the 
contractor’s  arguments  but  could  not  present  conclusive  proof 
that  the  neu  technique  uould  uork . 

After  completing  their  investigation,  the  study  group  met  to 
formulate  their  conclusions.  They  agreed  that  the  folloulng 
critical  questions  had  been  raised: 

a .  Could  the  neu  programming  technique  be  improved  enough 
to  meet  its  promised  high  productivity  for  softuare  development? 

b .  Uould  the  neu  programming  technique  handle  the 
revolutionary  requirements  of  Step  Tuo? 

c.  Should  the  Step  Tuo  development  continue  to  use  the-  neu 
technique? 

d.  Should  the  Step  One  cruiser  program  continue  to  use  the 
neu  technique? 

The  study  group  uas  divided  over  the  ansuers  to  these 
questions.  Some  believed  that  the  neu  technique  uas  fatally 
flaued  and  uould  never  uork.  Others  believed  that  recent 
improvements  shoued  that  the  process  could  be  Improved  rapidly . 

COR  Blngay  took  the  comments  of  each  member,  thanked  them 
for  their  participation,  and  proceeded  to  the  task  of  urltlng  his 
report  to  the  program  manager. 

The  basic  issue  uas  one  of  risk  versus  payoff.  If  the  neu 
programming  technique  met  its  goals,  it  uould  provide  significant 
cost  reduction*  over  the  life  cycle  of  TOS  softuare  programs.  The 
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greatest  payoff  uiould  be  realized  If  both  the  Step  One  and  Step 
Tuo  programs  uere  developed  uith  the  neu  technique. 

For  the  Step  One  cruiser  program,  there  uas  no,  less  risky 
alternative  to  continuing  the  program  as  it  uas  currently 
structured.  No  other  softuare  development  technique  —  including 
the  traditional  one  used  for  the  carrier  —  uould  allou  starting 
the  program  over  from  scratch  and  completing  it  in  less  than 
three  years.  The  cruiser  schedule  could  still  be  met  if  the  neu 
technique  could  be  made  more  productive.  He  recommended  staying 
uith  the  neu  technique  for  the  Step  One  cruiser  program, 
overlapping  the  test  phases,  and  investing  as  many  dollars  as 
possible  to  make  the  neu  technique  operate  better. 

CDR  Blngay  found  it  more  difficult  to  formulate  the  proper 
recommendation  for  Step  Tuo.  It  uas  early  enough  in  the 
development  to  change  the  structure  and  technical  basis  of  the 
program  and  still  complete  it  on  schedule.  But,  the  life  cycle 
costs  could  be  much  higher.  He  took  the  long  term  vieu  and 
recommended  that  the  neu  softuare  development  technique  remain 
the  basis  for  Step  Tuo. 

CDR  Blngay  submitted  his  report  to  the  program  manager  on 
April  fools  day,  having  missed  the  Ides  of  March.  The  follouing 
day,  the  program  manager  returned  the  report  and  asked  CDR  Blngay 
to  reconsider  his  recommendation  for  Step  Tuo.  The  program 
manager  didn’t  think  the  recommendation  uas  urong,  but  another 
revieu  of  the  technical  factors  might  yield  a  different  ansuer. 

As  he  left,  CDR  Blngay  thought;  "Hou  did  ue  get  into  this  mess?” 
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